코드 강화: 타입 안전성 권한 부여 및 권한 관리 심층 분석

복잡한 소프트웨어 개발의 세계에서 보안은 기능이 아니라 근본적인 요구사항입니다. 우리는 방화벽을 구축하고, 데이터를 암호화하며, 주입 공격으로부터 보호합니다. 하지만 흔하고 은밀한 취약점은 종종 눈에 띄게, 즉 애플리케이션 로직 깊숙한 곳에 숨어 있습니다: 바로 권한 부여입니다. 특히, 권한을 관리하는 방식이 그렇습니다. 수년 동안 개발자들은 겉으로는 무해해 보이는 패턴인 문자열 기반 권한에 의존해왔습니다. 이 방식은 시작하기는 간단하지만, 종종 취약하고 오류가 발생하기 쉬우며 안전하지 않은 시스템으로 이어집니다. 개발 도구를 활용하여 권한 부여 오류가 프로덕션에 도달하기 전에 잡아낼 수 있다면 어떨까요? 컴파일러 자체가 우리의 첫 번째 방어선이 될 수 있다면 어떨까요? 타입 안전성 권한 부여의 세계에 오신 것을 환영합니다.

이 가이드는 문자열 기반 권한의 취약한 세계에서 벗어나 강력하고 유지보수 가능하며 매우 안전한 타입 안전성 권한 부여 시스템을 구축하는 포괄적인 여정으로 여러분을 안내할 것입니다. 우리는 TypeScript의 실제 예시를 사용하여 '왜', '무엇을', '어떻게'를 탐구할 것이며, 이는 모든 정적 타입 언어에 적용할 수 있는 개념을 설명합니다. 이 가이드가 끝날 때쯤이면 이론을 이해할 뿐만 아니라 애플리케이션의 보안 상태를 강화하고 개발자 경험을 향상시키는 권한 관리 시스템을 구현할 실질적인 지식을 갖게 될 것입니다.

문자열 기반 권한의 취약성: 흔한 함정

본질적으로 권한 부여는 "이 사용자가 이 작업을 수행할 권한이 있는가?"라는 간단한 질문에 답하는 것입니다. 권한을 나타내는 가장 간단한 방법은 "edit_post" 또는 "delete_user"와 같은 문자열을 사용하는 것입니다. 이는 다음과 같은 코드로 이어집니다:

if (user.hasPermission("create_product")) { ... }

이 접근 방식은 처음에는 구현하기 쉽지만, 마치 모래성 같습니다. 종종 "매직 문자열"을 사용하는 것으로 불리는 이 관행은 상당한 양의 위험과 기술 부채를 초래합니다. 이 패턴이 왜 그렇게 문제가 많은지 분석해 봅시다.

오류의 연쇄

• 정숙한 오타: 이것이 가장 분명한 문제입니다. "create_product" 대신 "create_pruduct"를 확인하는 것과 같은 간단한 오타는 충돌을 일으키지 않습니다. 경고도 발생하지 않습니다. 검사는 단순히 조용히 실패하며, 접근 권한이 있어야 하는 사용자는 거부됩니다. 더 나쁜 것은 권한 정의의 오타가 실수로 허용되지 않아야 할 곳에 접근 권한을 부여할 수 있다는 것입니다. 이러한 버그는 추적하기가 매우 어렵습니다.
• 낮은 발견 가능성: 새로운 개발자가 팀에 합류할 때, 어떤 권한을 사용할 수 있는지 어떻게 알 수 있을까요? 그들은 모든 사용법을 찾기 위해 전체 코드베이스를 검색해야 합니다. 단일 진실 공급원도, 자동 완성도, 코드 자체에서 제공되는 문서도 없습니다.
• 리팩토링 악몽: 조직에서 "edit_post"를 "post:update"로 변경하는 등 보다 구조화된 명명 규칙을 채택하기로 결정했다고 상상해 보세요. 이는 백엔드, 프론트엔드, 잠재적으로 데이터베이스 항목까지 전체 코드베이스에 걸쳐 전역적이고 대소문자를 구분하는 검색 및 교체 작업을 필요로 합니다. 이는 단 한 번의 놓침으로 기능이 손상되거나 보안 취약점을 만들 수 있는 고위험 수동 프로세스입니다.
• 컴파일 시간 안전성 없음: 근본적인 약점은 권한 문자열의 유효성이 런타임에서만 확인된다는 것입니다. 컴파일러는 어떤 문자열이 유효한 권한인지 아닌지에 대해 전혀 알지 못합니다. "delete_user"와 "delete_useeer"를 동일하게 유효한 문자열로 간주하며, 오류 발견을 사용자나 테스트 단계로 미룹니다.

실패의 구체적인 예시

문서 접근을 제어하는 백엔드 서비스를 생각해 봅시다. 문서를 삭제하는 권한은 "document_delete"로 정의됩니다.

관리자 패널을 작업하는 개발자가 삭제 버튼을 추가해야 합니다. 그들은 다음과 같이 확인 코드를 작성합니다:

// In the API endpoint if (currentUser.hasPermission("document:delete")) { // Proceed with deletion } else { return res.status(403).send("Forbidden"); }

개발자는 새로운 규칙을 따라 밑줄(_) 대신 콜론(:)을 사용했습니다. 이 코드는 문법적으로 올바르며 모든 린트 규칙을 통과할 것입니다. 그러나 배포되면 어떤 관리자도 문서를 삭제할 수 없게 됩니다. 기능은 고장 났지만 시스템은 충돌하지 않습니다. 단순히 403 Forbidden 오류를 반환할 뿐입니다. 이 버그는 며칠 또는 몇 주 동안 눈에 띄지 않게 지나가 사용자에게 좌절감을 안겨주고 단일 문자 실수를 밝혀내기 위해 고통스러운 디버깅 세션을 필요로 할 수 있습니다.

이것은 전문적인 소프트웨어를 구축하는 지속 가능하거나 안전한 방법이 아닙니다. 더 나은 접근 방식이 필요합니다.

타입 안전성 권한 부여 소개: 컴파일러를 첫 번째 방어선으로

타입 안전성 권한 부여는 패러다임의 전환입니다. 컴파일러가 아무것도 모르는 임의의 문자열로 권한을 나타내는 대신, 프로그래밍 언어의 타입 시스템 내에서 명시적인 타입으로 정의합니다. 이 간단한 변경은 권한 유효성 검사를 런타임 문제가 아닌 컴파일 시간 보장으로 이동시킵니다.

타입 안전성 시스템을 사용하면 컴파일러는 유효한 권한의 전체 집합을 이해합니다. 존재하지 않는 권한을 확인하려고 하면 코드가 컴파일조차 되지 않습니다. 이전 예시의 "document:delete"와 "document_delete"의 오타는 파일을 저장하기도 전에 코드 편집기에서 즉시 빨간색 밑줄로 표시되어 감지될 것입니다.

핵심 원칙

• 중앙 집중식 정의: 모든 가능한 권한은 단일의 공유된 위치에 정의됩니다. 이 파일 또는 모듈은 전체 애플리케이션 보안 모델의 부인할 수 없는 진실의 원천이 됩니다.
• 컴파일 시간 검증: 타입 시스템은 검사, 역할 정의 또는 UI 구성 요소 등 권한에 대한 모든 참조가 유효하고 기존의 권한임을 보장합니다. 오타 및 존재하지 않는 권한은 불가능합니다.
• 향상된 개발자 경험(DX): 개발자들은 user.hasPermission(...)을 입력할 때 자동 완성 같은 IDE 기능을 얻습니다. 사용 가능한 모든 권한의 드롭다운 목록을 볼 수 있어 시스템이 자체적으로 문서화되고 정확한 문자열 값을 기억해야 하는 정신적 부담을 줄여줍니다.
• 확신 있는 리팩토링: 권한 이름을 변경해야 하는 경우 IDE의 내장 리팩토링 도구를 사용할 수 있습니다. 소스에서 권한 이름을 변경하면 프로젝트 전체의 모든 사용처가 자동으로 안전하게 업데이트됩니다. 한때 고위험 수동 작업이었던 것이 사소하고 안전하며 자동화된 작업이 됩니다.

기반 구축: 타입 안전성 권한 시스템 구현

이론에서 실천으로 나아갑시다. 우리는 처음부터 완전한 타입 안전성 권한 시스템을 구축할 것입니다. 예시에서는 강력한 타입 시스템이 이 작업에 완벽하게 적합하기 때문에 TypeScript를 사용할 것입니다. 그러나 기본 원칙은 C#, Java, Swift, Kotlin 또는 Rust와 같은 다른 정적 타입 언어에 쉽게 적용될 수 있습니다.

1단계: 권한 정의

가장 중요하고 첫 번째 단계는 모든 권한에 대한 단일 진실의 원천을 만드는 것입니다. 이를 달성하는 데는 여러 가지 방법이 있으며, 각 방법마다 장단점이 있습니다.

옵션 A: 문자열 리터럴 유니온 타입 사용

이것은 가장 간단한 접근 방식입니다. 가능한 모든 권한 문자열의 유니온인 타입을 정의합니다. 소규모 애플리케이션에는 간결하고 효과적입니다.

// src/permissions.ts export type Permission = | "user:create" | "user:read" | "user:update" | "user:delete" | "post:create" | "post:read" | "post:update" | "post:delete";

장점: 작성 및 이해가 매우 간단합니다.
단점: 권한 수가 증가함에 따라 다루기 어려워질 수 있습니다. 관련 권한을 그룹화하는 방법을 제공하지 않으며, 사용할 때 여전히 문자열을 직접 입력해야 합니다.

옵션 B: Enum 사용

Enum은 관련 상수를 단일 이름 아래에 그룹화하는 방법을 제공하여 코드를 더 읽기 쉽게 만들 수 있습니다.

// src/permissions.ts export enum Permission { UserCreate = "user:create", UserRead = "user:read", UserUpdate = "user:update", UserDelete = "user:delete", PostCreate = "post:create", // ... and so on }

장점: 명명된 상수(Permission.UserCreate)를 제공하여 권한 사용 시 오타를 방지할 수 있습니다.
단점: TypeScript enum은 몇 가지 미묘한 차이가 있으며 다른 접근 방식보다 유연성이 떨어질 수 있습니다. 유니온 타입에 대한 문자열 값을 추출하려면 추가 단계가 필요합니다.

옵션 C: Object-as-Const 접근 방식 (권장)

이것은 가장 강력하고 확장 가능한 접근 방식입니다. 우리는 TypeScript의 `as const` 단언을 사용하여 권한을 깊게 중첩된 읽기 전용 객체로 정의합니다. 이는 조직화, 점 표기법을 통한 발견 가능성(예: `Permissions.USER.CREATE`), 그리고 모든 권한 문자열의 유니온 타입을 동적으로 생성하는 능력이라는 모든 장점을 제공합니다.

설정 방법은 다음과 같습니다:

// src/permissions.ts // 1. Define the permissions object with 'as const' export const Permissions = { USER: { CREATE: "user:create", READ: "user:read", UPDATE: "user:update", DELETE: "user:delete", }, POST: { CREATE: "post:create", READ: "post:read", UPDATE: "post:update", DELETE: "post:delete", }, BILLING: { READ_INVOICES: "billing:read_invoices", MANAGE_SUBSCRIPTION: "billing:manage_subscription", } } as const; // 2. Create a helper type to extract all permission values type TPermissions = typeof Permissions; // This utility type recursively flattens the nested object values into a union type FlattenObjectValues = T extends object ? FlattenObjectValues : T; // 3. Create the final union type of all permissions export type AllPermissions = FlattenObjectValues; // The generated 'AllPermissions' type will be: // "user:create" | "user:read" | "user:update" | "user:delete" | ... and so on

이 접근 방식은 애플리케이션이 성장함에 따라 매우 중요한 명확하고 계층적인 권한 구조를 제공하므로 우수합니다. 검색하기 쉽고, `AllPermissions` 타입이 자동으로 생성되므로 유니온 타입을 수동으로 업데이트할 필요가 없습니다. 이것은 나머지 시스템에 사용할 기반입니다.

2단계: 역할 정의

역할은 단순히 이름이 지정된 권한 모음입니다. 이제 `AllPermissions` 타입을 사용하여 역할 정의도 타입 안전성을 보장할 수 있습니다.

// src/roles.ts import { Permissions, AllPermissions } from './permissions'; // Define the structure for a role export type Role = { name: string; description: string; permissions: AllPermissions[]; }; // Define a record of all application roles export const AppRoles: Record = { GUEST: { name: 'Guest', description: 'Limited access for anonymous users.', permissions: [ Permissions.POST.READ, // Can read posts Permissions.USER.READ, // Can view user profiles ], }, EDITOR: { name: 'Editor', description: 'Can create and manage their own content.', permissions: [ Permissions.POST.READ, Permissions.POST.CREATE, Permissions.POST.UPDATE, // Note: This doesn't specify *which* post. We'll address this later. Permissions.POST.DELETE, Permissions.USER.READ, ], }, ADMIN: { name: 'Administrator', description: 'Full access to all system features.', // Dynamically grant all permissions to the admin permissions: Object.values(Permissions).flatMap(resource => Object.values(resource)), }, }; // We can also create a type for our role keys for added safety export type AppRoleKey = keyof typeof AppRoles; // "GUEST" | "EDITOR" | "ADMIN"

권한을 할당하기 위해 `Permissions` 객체(예: `Permissions.POST.READ`)를 사용하는 방식에 주목하세요. 이는 오타를 방지하고 유효한 권한만 할당하도록 보장합니다. `ADMIN` 역할의 경우, 새로운 권한이 추가될 때 관리자가 자동으로 이를 상속하도록 보장하기 위해 `Permissions` 객체를 프로그래밍 방식으로 평탄화하여 모든 권한을 부여합니다.

3단계: 타입 안전성 검사 함수 생성

이것은 우리 시스템의 핵심입니다. 사용자가 특정 권한을 가지고 있는지 확인할 수 있는 함수가 필요합니다. 핵심은 함수의 시그니처에 있으며, 이는 유효한 권한만 검사할 수 있도록 강제할 것입니다.

먼저, `User` 객체가 어떻게 생겼는지 정의해 봅시다:

// src/user.ts import { AppRoleKey } from './roles'; export type User = { id: string; email: string; roles: AppRoleKey[]; // The user's roles are also type-safe! };

이제 권한 부여 로직을 구축해 봅시다. 효율성을 위해 사용자의 전체 권한 집합을 한 번 계산한 다음 해당 집합에 대해 확인하는 것이 가장 좋습니다.

// src/authorization.ts import { User } from './user'; import { AppRoles } from './roles'; import { AllPermissions } from './permissions'; /** * Computes the complete set of permissions for a given user. * Uses a Set for efficient O(1) lookups. * @param user The user object. * @returns A Set containing all permissions the user has. */ function getUserPermissions(user: User): Set { const permissionSet = new Set(); user.roles.forEach(roleKey => { const role = AppRoles[roleKey]; if (role) { role.permissions.forEach(permission => { permissionSet.add(permission); }); } }); return permissionSet; } /** * The core type-safe function to check if a user has a specific permission. * @param user The user to check. * @param permission The permission to check for. Must be a valid AllPermissions type. * @returns True if the user has the permission, false otherwise. */ export function hasPermission( user: User | null, permission: AllPermissions ): boolean { if (!user) { return false; } const userPermissions = getUserPermissions(user); return userPermissions.has(permission); }

마법은 `hasPermission` 함수의 `permission: AllPermissions` 매개변수에 있습니다. 이 시그니처는 TypeScript 컴파일러에게 두 번째 인수가 우리가 생성한 `AllPermissions` 유니온 타입의 문자열 중 하나여야 한다는 것을 알려줍니다. 다른 문자열을 사용하려는 모든 시도는 컴파일 시간 오류를 발생시킬 것입니다.

실제 사용

이것이 우리의 일상적인 코딩을 어떻게 변화시키는지 봅시다. Node.js/Express 애플리케이션에서 API 엔드포인트를 보호한다고 상상해 보세요:

import { hasPermission } from './authorization'; import { Permissions } from './permissions'; import { User } from './user'; app.delete('/api/posts/:id', (req, res) => { const currentUser: User = req.user; // Assume user is attached from auth middleware // This works perfectly! We get autocomplete for Permissions.POST.DELETE if (hasPermission(currentUser, Permissions.POST.DELETE)) { // Logic to delete the post res.status(200).send({ message: 'Post deleted.' }); } else { res.status(403).send({ error: 'You do not have permission to delete posts.' }); } }); // Now, let's try to make a mistake: app.post('/api/users', (req, res) => { const currentUser: User = req.user; // The following line will show a red squiggle in your IDE and FAIL TO COMPILE! // Error: Argument of type '"user:creat"' is not assignable to parameter of type 'AllPermissions'. // Did you mean '"user:create"'? if (hasPermission(currentUser, "user:creat")) { // Typo in 'create' // This code is unreachable } });

우리는 전체 버그 범주를 성공적으로 제거했습니다. 컴파일러는 이제 보안 모델을 시행하는 데 적극적으로 참여하고 있습니다.

시스템 확장: 타입 안전성 권한 부여의 고급 개념

간단한 역할 기반 접근 제어(RBAC) 시스템은 강력하지만, 실제 애플리케이션은 종종 더 복잡한 요구 사항을 가집니다. 데이터 자체에 따라 달라지는 권한은 어떻게 처리할까요? 예를 들어, `EDITOR`는 게시물을 업데이트할 수 있지만, 자신이 작성한 게시물만 업데이트할 수 있습니다.

속성 기반 접근 제어(ABAC) 및 리소스 기반 권한

여기서 속성 기반 접근 제어(ABAC) 개념을 소개합니다. 우리는 시스템을 확장하여 정책 또는 조건을 처리합니다. 사용자는 일반적인 권한(예: `post:update`)을 가질 뿐만 아니라, 접근하려는 특정 리소스와 관련된 규칙도 충족해야 합니다.

우리는 정책 기반 접근 방식으로 이를 모델링할 수 있습니다. 특정 권한에 해당하는 정책 맵을 정의합니다.

// src/policies.ts import { User } from './user'; // Define our resource types type Post = { id: string; authorId: string; }; // Define a map of policies. The keys are our type-safe permissions! type PolicyMap = { [Permissions.POST.UPDATE]?: (user: User, post: Post) => boolean; [Permissions.POST.DELETE]?: (user: User, post: Post) => boolean; // Other policies... }; export const policies: PolicyMap = { [Permissions.POST.UPDATE]: (user, post) => { // To update a post, the user must be the author. return user.id === post.authorId; }, [Permissions.POST.DELETE]: (user, post) => { // To delete a post, the user must be the author. return user.id === post.authorId; }, }; // We can create a new, more powerful check function export function can(user: User | null, permission: AllPermissions, resource?: any): boolean { if (!user) return false; // 1. First, check if the user has the basic permission from their role. if (!hasPermission(user, permission)) { return false; } // 2. Next, check if a specific policy exists for this permission. const policy = policies[permission]; if (policy) { // 3. If a policy exists, it must be satisfied. if (!resource) { // The policy requires a resource, but none was provided. console.warn(`Policy for ${permission} was not checked because no resource was provided.`); return false; } return policy(user, resource); } // 4. If no policy exists, having the role-based permission is enough. return true; }

이제 우리 API 엔드포인트는 더 미묘하고 안전해집니다:

import { can } from './policies'; import { Permissions } from './permissions'; app.put('/api/posts/:id', async (req, res) => { const currentUser = req.user; const post = await db.posts.findById(req.params.id); // Check the ability to update this *specific* post if (can(currentUser, Permissions.POST.UPDATE, post)) { // User has the 'post:update' permission AND is the author. // Proceed with update logic... } else { res.status(403).send({ error: 'You are not authorized to update this post.' }); } });

프론트엔드 통합: 백엔드와 프론트엔드 간의 타입 공유

이 접근 방식의 가장 중요한 이점 중 하나는 특히 프론트엔드와 백엔드 모두에서 TypeScript를 사용할 때 이러한 타입을 공유할 수 있다는 것입니다. `permissions.ts`, `roles.ts` 및 기타 공유 파일을 모노레포(Nx, Turborepo 또는 Lerna와 같은 도구 사용) 내의 공통 패키지에 배치하면 프론트엔드 애플리케이션이 권한 부여 모델을 완전히 인식하게 됩니다.

이를 통해 사용자의 권한에 따라 요소를 조건부로 렌더링하는 것과 같은 강력한 패턴을 UI 코드에서 사용할 수 있으며, 이 모든 것은 타입 시스템의 안전성과 함께 제공됩니다.

React 구성 요소를 생각해 봅시다:

// In a React component import { Permissions } from '@my-app/shared-types'; // Importing from a shared package import { useAuth } from './auth-context'; // A custom hook for authentication state interface EditPostButtonProps { post: Post; } const EditPostButton = ({ post }: EditPostButtonProps) => { const { user, can } = useAuth(); // 'can' is a hook using our new policy-based logic // The check is type-safe. The UI knows about permissions and policies! if (!can(user, Permissions.POST.UPDATE, post)) { return null; // Don't even render the button if the user can't perform the action } return Edit Post; };

이것은 판도를 바꾸는 일입니다. 프론트엔드 코드는 더 이상 UI 가시성을 제어하기 위해 추측하거나 하드코딩된 문자열을 사용할 필요가 없습니다. 백엔드의 보안 모델과 완벽하게 동기화되며, 백엔드의 권한 변경 사항은 업데이트되지 않으면 프론트엔드에서 즉시 타입 오류를 발생시켜 UI 불일치를 방지합니다.

비즈니스 사례: 조직이 타입 안전성 권한 부여에 투자해야 하는 이유

이 패턴을 채택하는 것은 단순한 기술적 개선 이상입니다. 이는 실질적인 비즈니스 이점을 제공하는 전략적 투자입니다.

• 버그의 대폭 감소: 권한 부여와 관련된 전체 유형의 보안 취약점 및 런타임 오류를 제거합니다. 이는 더 안정적인 제품과 비용이 많이 드는 프로덕션 사고 감소로 이어집니다.
• 개발 속도 가속화: 자동 완성, 정적 분석 및 자체 문서화 코드는 개발자를 더 빠르고 자신감 있게 만듭니다. 권한 문자열을 찾거나 조용한 권한 부여 실패를 디버깅하는 데 시간이 덜 소요됩니다.
• 간소화된 온보딩 및 유지보수: 권한 시스템은 더 이상 부족의 지식이 아닙니다. 새로운 개발자는 공유된 타입을 검사하여 보안 모델을 즉시 이해할 수 있습니다. 유지보수 및 리팩토링은 위험이 낮고 예측 가능한 작업이 됩니다.
• 향상된 보안 상태: 명확하고 명시적이며 중앙에서 관리되는 권한 시스템은 감사하고 추론하기 훨씬 쉽습니다. "누가 사용자를 삭제할 권한을 가지고 있는가?"와 같은 질문에 답하는 것이 사소한 일이 됩니다. 이는 규정 준수 및 보안 검토를 강화합니다.

도전 과제 및 고려 사항

강력하지만, 이 접근 방식에도 몇 가지 고려 사항이 있습니다:

• 초기 설정 복잡성: 코드 전체에 단순히 문자열 검사를 분산하는 것보다 더 많은 사전 아키텍처적 사고가 필요합니다. 그러나 이 초기 투자는 프로젝트의 전체 수명 주기 동안 이익을 가져다줍니다.
• 규모에서의 성능: 수천 개의 권한이나 극도로 복잡한 사용자 계층 구조를 가진 시스템에서 사용자 권한 집합(`getUserPermissions`)을 계산하는 프로세스가 병목 현상이 될 수 있습니다. 이러한 시나리오에서는 캐싱 전략(예: 계산된 권한 집합을 저장하기 위해 Redis 사용)을 구현하는 것이 중요합니다.
• 도구 및 언어 지원: 이 접근 방식의 모든 이점은 강력한 정적 타이핑 시스템을 가진 언어에서 실현됩니다. Python 또는 Ruby와 같은 동적 타입 언어에서 타입 힌팅 및 정적 분석 도구를 사용하여 유사하게 구현할 수 있지만, TypeScript, C#, Java, Rust와 같은 언어에 가장 적합합니다.

결론: 더 안전하고 유지보수 가능한 미래 구축

우리는 매직 문자열의 위험한 지형에서 타입 안전성 권한 부여라는 잘 요새화된 도시로 여행했습니다. 권한을 단순한 데이터가 아니라 애플리케이션 타입 시스템의 핵심 부분으로 취급함으로써 컴파일러를 단순한 코드 검사기에서 경계하는 보안 요원으로 변화시킵니다.

타입 안전성 권한 부여는 개발 수명 주기에서 가능한 한 일찍 오류를 포착하는 현대 소프트웨어 공학 원칙인 '쉬프트 레프트'의 증거입니다. 이는 코드 품질, 개발자 생산성, 그리고 가장 중요하게는 애플리케이션 보안에 대한 전략적 투자입니다. 자체 문서화되고, 리팩토링하기 쉬우며, 오용할 수 없는 시스템을 구축함으로써 더 나은 코드를 작성하는 것을 넘어 애플리케이션과 팀을 위한 더 안전하고 유지보수 가능한 미래를 구축하는 것입니다. 다음 번에 새 프로젝트를 시작하거나 기존 프로젝트를 리팩토링할 때 스스로에게 물어보세요: 당신의 권한 부여 시스템은 당신을 위해 일하고 있습니까, 아니면 당신에게 불리하게 작용하고 있습니까?